Although the Internet was originally conceived as a communications mechanism, billions of commercial transactions are conducted daily and an entire field has spawned to facilitate and manage the networked communications and transactions.
The client/server model is one form of infrastructure for network computing, and is widely used by many business applications. For a typical client/server architecture each computer or process on the network is either a client or a server. The servers are generally defined as computers, similar devices, processes or computing resources on a network that manage network resources. The servers come in varied forms such as those computing devices dedicated to managing storage devices (file servers), printers (print servers), network traffic (network servers), and databases (database servers). A file server performs as a storage mechanism, dedicated to storing and allocating files accessible to certain users. A print server manages one or more printer or printer-type devices. A network server manages network traffic. A database server processes database queries and related aspects. The servers may be dedicated and perform no other tasks besides their server functions. Alternatively, multi-processing systems can employ a single computer that executes multiple programs simultaneously.
Clients can be personal computers (PC's), workstations, servers or similar computing devices that run one or more applications. The client/server relationship describes the interaction between computer programs, wherein one program, the client, makes a service request from another program, the server, which fulfills the request. Although the client/server concept may be used by programs within a single server, it is more relevant in a network environment. On a network, the client/server model provides a convenient way to interconnect programs that are distributed across disparate locations allowing seamless transactions. For example, a user can easily check the user's bank account balance using the user's home computer. A client program in the home computer forwards a request to a server program at the bank computer. The server program may in turn forward the request to various bank client programs that eventually sends a request to a database server at a bank computer to retrieve the user's account balance. The balance information is returned back to the bank data client and forwards the information to the client in the user's computer which is displayed to the user. There are numerous applications and functions performed by servers and the list continues to grow and expand.
From a processing perspective of a typical client/server model, one server has an active process, sometimes called a daemon that awaits a client request. Once a client request is recognized by the daemon, the server takes some action based upon the client request and invokes one or more programs. This is typically a tightly coupled proprietary binary protocol. In reality, multiple client programs may share the services of a common server program, wherein both client programs and server programs are often part of a larger program or application. By way of illustration, an Internet Web browser is a client program that requests services, such as sending of Web pages or files from a Web server or Hypertext Transport Protocol (HTTP) server in another computer/server on the Internet. The traditional client/server model of a Web server/Web page system provides the user with a graphical user interface (GUI) display on the Web browser. Likewise, the client computer allows client requests for files from File Transfer Protocol (FTP) servers on other computers on the Internet. Another form of network architecture is known as a peer-to-peer architecture because each node has equivalent responsibilities.
Another network infrastructure is called Web services. Web services, sometimes called application services, or Service-Oriented Architecture (SOA), provide a means for businesses to communicate with each other and with clients, wherein the Web services allow organizations to communicate data without intimate knowledge of the various IT systems. Service oriented architecture (SOA) includes services that form part of the infrastructure of a business enterprise, wherein services can become building blocks for application development and deployment, allowing rapid application development and avoiding redundant code. Each service may embody a set of business logic or business rules that can be bound to the surrounding environment, such as the source of the data inputs for the service or the targets for the data outputs of the service. A service is essentially a function that is well-defined, self-contained, and does not depend on the context or state of other services. Web services in one embodiment represent a schema of decentralized systems that are open and loosely coupled with disparate applications woven together by the exchange of extensible mark-up language (XML) messages.
Web services typically use the XML language to create a robust connection, wherein the service-oriented architectures are essentially a collection of services that communicate with each other via a connecting mechanism. The communication may simply pass data or could involve two or more services coordinating some activity.
Unlike the general client/server models, Web services do not provide the user with a GUI, but instead share information, data and processes through an interface across a network. The applications provide the interface and not the users, (e.g., browsers or HTML) thus developers can add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to the users. In practice, Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and the Web services are not tied to any one operating system (OS) or programming language. By way of example, service-oriented architectures has been successfully implemented using DCOM or Object Request Brokers (ORBs) based on the CORBA specification.
Web services provide the ability to decouple the application into functional parts, develop those parts independently using any platform and any language, and have it all work together seamlessly. Web services technology makes Service Oriented Architecture a viable option provided that there is sufficient interoperability of the components. In one implementation, Web services is used to describe a standardized way of integrating applications using the extensible mark-up language (XML), Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI) open standards over an Internet protocol backbone. In this particular embodiment, XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available.
The Web Services Description Language (WSDL) uses a format, such as XML format, for describing network services (often web services) as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
The interoperability for the Web services is achieved via open specification and through the technology being used (i.e. XML and SOAP) and through the careful designing of the developers creating a Web service. The interoperability is an important aspect of the Web services, and to address the problems of interoperability, the World Wide Web Consortium (W3C) created the Web Service Description Language (WSDL) to bring together the different styles of sending SOAP messages and to reconcile them with a common interface. In simple terms, WSDL allows a service to describe what it expects a SOAP message to look like. The WSDL 1.1 specification allows a service to be implemented using a mix of the different styles and encodings. Although the goal of the W3C was to standardize the different messaging styles under the umbrella of WSDL 1.1, the specification suffered from ambiguity and independent toolkit providers interpreted the specification loosely thereby implementing language-specific idiosyncrasies between various toolkits.
Web Services using SOAP provide a means by which computer software applications can interact across a network. A client application running on one machine on the network sends a XML SOAP Request message, usually but not necessarily using HTTP, Java Message Service (JMS), or Message Queuing, to the Web Service hosted on some other machine on the network; that Service processes the SOAP Request and then sends back a XML SOAP Response message.
The processing involves certain defined Message Exchanges. The pair of messages, the Request and Response, constitutes a Message Exchange. This is the most common type of message exchange—request/response—currently found in Web Service communication. There are other possible forms, e.g. One Way, in which the messages sent by the client have no corresponding response from the service, or Notification, in which the service itself sends notification messages of its own accord, having received no Request message from the client to initiate the action.
A particular session of communication between the client and service can include any number of SOAP Messages that go back and forth between the client and the service. Further, more complex systems can include not just two computers, the client and service, but rather several computers, each of which may be running software applications that can themselves include multiple clients and services within them.
The Service Description is another component of these communications and is typically represented in the form of one or more WSDL (Web Service Description Language) document(s) and possibly several associated XML Schema Document(s). These documents are often generated dynamically by the Web Server on which the Service application is running. They can, however, also be provided as separate, standalone documents, independent of any specific machine or application. The WSDL and XML Schema Documents that form the service description express the ‘contract’ between the service and the client applications. In particular, the document includes formal, machine consumable descriptions of the valid Request Messages that are understood by the service application and the corresponding Response Messages that will be produced by it. It also includes human readable documentation and explanations of these Message Exchanges, so that the creators of client applications to the service can understand the intended use and expected behavior.
In order to promote more consistent interpretation of the Web service specifications, the Web Services Interoperability Organization (WS-I) was formed to promulgate specific guidelines and recommended practices for using and developing Web services. The WS-I provided the Basic Profile (BP) to address known interoperability issues and is predominantly a restriction of the original WSDL 1.1 specification to the most interoperable practices. However, even within the WS-I, at present there has been no absolute consensus of interoperability and the formulation to ensure the Web services were indeed interoperable.
While there are many toolkits to help automate the design process of Web services, not all the toolkits behave in the same way, and this leads to a wide range of interoperability problems. In current practice, the entire development team must be integrally involved to ensure that the service is compatible with other interoperable toolkits. The Developer needs to have interoperability concerns in mind from the beginning of the development cycle throughout the entire design and implementation. The Project Manager needs to make it a policy to test for interoperability as part of the quality of their service. The Tester has to continually check the quality of the service once in operation. Interoperability has become such a major component to the quality of a Web service, it is absolutely necessary to have tools to help detect and solve interoperability problems when they arise.
In theory, interoperability requires an infinite amount of testing under all possible circumstances. However, in practice, the service is continually monitored and any breakage is repaired and the fix becomes part of the regression tests thereby improving the testing process. The WS-I established a suite of test tools that check a Web service's message exchanges and WSDL against the assertions in the BP. The test tools are essentially passive and require the tester to invoke the service manually, capture the SOAP messages off the wire, and log them in the WS-I's log format. Using the tools effectively is not an easy task and the output of their analysis is a large, flat report. The report serves as an indicator of a service that has failed, but using the report to determine exactly what went wrong and how to begin fixing the problem is difficult and tedious.
In traditional environments, Support teams work with stand-alone or “silo” applications that perform all functions within a closed system. Diagnosing and successfully addressing problems within these environments, though not always easy, offers a fairly predictable support path. But Web services present a significant change to this model. Unlike closed systems, Web services are designed to be highly distributed and flexible in order to interoperate with other services in service-oriented architectures (SOAs), within a single organization or among worldwide networks. So when a problem occurs with a particular supported service, finding its root cause is significantly more complex in that the problem may not have originated within that service, but rather with any one of a large number of other services with which that service interoperates.
Web services present a number of additional challenges for support teams. First, they must recognize the need to support a more technically sophisticated customer base that includes architects, developers, testers, and operations staff, either within their organization or with outside partners and customers. They must also recognize that, unlike application or Web sites, Web services are built upon application programming interfaces (APIs) that do not contain a user interface, raising the complexity of the support equation.
Successfully incorporating Web services support into the support environment requires a transition to a new and forward-looking set of tools and best practices.
Organizations face a number of new challenges as they begin supporting Web services. Chief among these is that they will find themselves supporting a very different set of clients. Traditionally, support teams work with end-users of specific applications. With Web services, however, the client base consists largely of developers, testers, operations, and support staff. Supporting these more technically sophisticated groups requires a very different set of skills and tools.
Another issue facing teams supporting Web services is the lack of a graphical user interface. In traditional application support environments, support teams and customers resolve problems by viewing an application together to assess at what point a problem arises. Having a common user interface provides a common frame of reference that allows for more efficient collaboration. Web services problems, however, are not as visual or apparent as are problems related to a Web application or site since they are built using APIs, which do not contain a user interface. This leaves no visual point of reference for a client and a support team member to discuss a Web services problem in its full context.
In the current Web services support methods, diagnosing and acting upon problems related to a Web service requires a good deal of collaboration between customers and support teams. But this process is made difficult by a number of technical barriers, including those mentioned previous. This has led to a system of less formalized, inefficient support methods. The most common method consists of an exchange of e-mail containing snippets of complex XML data related to a particular problem. The lack of a formal process and context inherent in this method make it vulnerable to spinning out of control, leading to a poor customer support experience.
By way of example, a typical scenario begins with a customer contacting a support team member to discuss a problem encountered with a Web service. The team member asks the customer to submit a code sample related to the problem via e-mail for analysis. However, when the team member receives the e-mail, the team member typically does not have sufficient information to diagnose the problem because the customer submitted code that lacked critical information such as the time at which a problem occurred, the particular server or servers that were accessed, the data sent to and/or received from the service, and a number of other vital details.
At this point the support representative typically contacts the customer to request that customer submit a further test case or complete code in order to provide a clearer picture of the problem. However, once received, other issues become evident. Since the code was sent via e-mail, the team member is not able to perform any debugging and must take the step of writing a client application in order to emulate the problem. But, in this example, the client's code was written using Microsoft's .NET platform while the team member works strictly within a Java environment, making it impossible to debug the code and to create a reproducible case in its native format.
The result is that the customer does not receive a satisfactory support experience while the support rep spends a larger amount of time than is usually spent on a particular case, but is not able to provide effective help for the customer. This level of inefficiency can have significant economic and relationship consequences for any organization supporting Web services.
Given the potential for a poor customer support experience and limited success within the support team, a set of requirements need to be in place to ensure that support teams have the tools and processes they need to optimize their environment for Web services support and instill greater confidence from customers.
One of the requirements for proper web services support is adequate training. Web services require a very different set of support skills. It is essential that support teams receive an adequate amount of training to better understand the unique character of Web services and the specific needs of their new client base. Given the rapid rate of Web services adoption, additional headcount may be necessary to bring these new skills and experience more quickly into the support team
Another web services requirement is the appropriate tools and processes. Supporting Web services successfully requires tools and processes that can address a new set of support challenges. To be successful, tools should include the ability to capture problem data in its entirety to provide a complete view of a problem, and the ability to capture, view, analyze, and perform tests on data, regardless of the platform in which it was created.
Diagnosing and resolving Web services issues is a highly collaborative process. As such, customers and support teams must have tools at their disposal that allow them to view problem data together in order to talk through a problem. Without this visibility, both sides are forced into the laborious task of attempting to describe in detail a highly technical problem or trading e-mail containing incomplete data. In order to fully understand the path leading to a Web service failure, support representatives should be able to reproduce and analyze the problem. Doing this requires a tool that allows for complete problem capture and storage such that it eliminates the need to create ad-hoc clients from customer-supplied code snippets.
Web services have gained credibility as a reliable and effective means of fulfilling the goal of integrating data and applications worldwide. But with this promise comes a level of complexity and interdependence that can lead to serious problems for organizations not prepared to handle their unique support requirements. Organizations that are supporting Web services must be able to support their clients in a way that provides full context and insight into a problem while not relying on a particular platform.
What is needed is a way for support teams and customers to diagnose and resolve Web services problems intuitively within a highly visual environment. The Support Solution should also includes a suite of best practices that help organizations provide a high-quality support experience for customers while driving down costs by creating a more efficient and responsive support environment. What is needed are techniques for collecting and managing artifacts that comprise the problem context related to a distributed XML-based application problem, and packaging the context in a way that facilitates testing, supporting, maintaining, troubleshooting, debugging and communicating a reproducible problem. What is needed is a Web service tool that can analyze, detect, and resolve the interoperability issues.